1. Field
This disclosure generally relates to software development. More particularly, the disclosure relates to problem determination (“PD”) for handling software errors.
2. General Background
PD is an approach utilized by software developers to find bugs, i.e., errors, in software code. The current PD methodology involves debugging and/or reading output generated by the software. Examples of this output include a trace file, output on a screen display, etc.
Debugging involves starting a software application or application server in a special mode. Further, debugging involves the use of setting break points in this special mode so that the software application or application server will stop at the break points during the execution of the software code. An example of such software code may be business logic utilized in a business transactional system. When the software application or application server stops at a break point, an analysis can be performed of the current state of the execution at the particular break point. As an example, the values of particular variables can be analyzed at the break point. The execution of the code can be stepped through, e.g., one line at a time, to analyze how the state of these variables changes in response to each subsequent line of code after the break point. Further, the execution context can be changed so that the software application or application server can choose different execution paths.
PD by output is normally performed by reading a trace file in a text editor. Accordingly, the text editor is helpful in performing text searches for exception or execution related key words. The portions found by the text editor can then be filtered out so that particular parts of the trace filed can be focused on. For example, a trace filed can be searched for traces regarding a particular thread. Anything unrelated to that particular thread can be filtered outs so that the PD analysis can focus on the traces for the thread. Another example involves filtering out a trace file for everything except for traces generated by a particular component, e.g., a logger.
With respect to software product support, a support team utilizing PD with a trace file is often preferable to debugging because of the communication barrier, e.g., firewall, that often exists between the support team at the software vendor site and the customer at the customer site. Budgetary concerns normally prevent the support team traveling to the customer site as a large expense could be incurred for travel in each reporting case. Further, customer policy may prevent support team visits because of the sensitivity of the customer's data and production environment. The customer normally does not allow PD to be performed by the support team of a software vendor in the customer's live system.
Further, utilizing the traditional debugging methodology for PD in complex software systems built on top of a Service Oriented Architecture (“SOA”) presents a number of drawbacks. One drawback is with respect to the traditional debugging methodology being utilized at the source code level. When end users develop an SOA application, they see assembly diagrams of services that illustrate what those services are, how they are connected with each other, and what types of invocation result when the services are invoked (e.g., synchronous, asynchronous, etc.). As an SOA service is built on top of many layers of supporting components, debugging at the source code level is a very big challenge to the end user.
Another drawback is that the traditional debugging methodology needs a production system to be in a special mode. For example, to debug an application server, the application server needs to be started with the debugging option turned on. The performance impact on the production system is so significant that a customer will not allow debugging on its running system.
Although analysis through a trace file is preferable to the traditional debugging methodology, such analysis also has drawbacks. For instance, a trace file is normally difficult to understand. Traditionally, the trace file can only be understood by the person who developed the application or component that generates certain trace. This presents quite a bit of difficulty when many people are involved in the development. As an example, an enterprise software product could be developed by hundreds, if not thousands of people. To scale the development, the product is typically developed through many components. A developer typically only understands the component that he or she develops. Therefore, that developer will typically only understand the trace generated by his or her component.
Another drawback of the traditional trace analysis involves the tooling that is utilized. For instance, the tooling used to read a trace file typically is a simple text editor, which does not have much logic to help analyze a trace file. Even for a product that has a log analyzer to analyze the log/trace file, the logic is specific to the product or certain problem type. Accordingly, the current tooling does not help with understanding the high level execution logic and the cause of a problem.
Finally, the utilizing both the traditional debugging methodology and the traditional trace analysis presents additional drawbacks. Trace based PD and debugging based PD are two separated activities. The tooling utilities are very different. The knowledge learned from one activity can not be automatically applied to the other activity.